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DEVICE DELIVERING A SERVICE USING AN ASSOCIATED PORTABLE MEMORY, AND RELAYING 
MEANS FOR ALLOWING ACTIVATION OF AN APPLICATION OF THE PORTABLE MEMORY OF THE 
FIRST DEVICE BY A SECOND DEVICE 



5 1 Technical applicafion field 

The invention relates to a first device for delivering a service using an 
application lodged in a portable object, comprising a portable object reader for 
receiving said portable object, the portable object incorporating at least one 
application and the first device including resources for activating said 
10 application. The general problem to be solved is to allow, t)eside usual activation 
of an application of the portable object by the resident resources of the first 
device, activation of an application of the portable object by a second device, 
Independentiy of said resident resources. 



15 This feature offers several advantages, in particular : 

-in case the resources of the first device are regarded as too limited for ciertain * 
management operations of the application (for example, the keyboard and 
display are small), activation by the second device may offer extended 
resources ; 

20 -for executing certain operations of the application, it may t>e desired or even 
required that only said second device will manage said operations. For example, 
ft may be decided that some secure operations such as a funds transfer with the 
portable object will be only possible if executed by said second device. 
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The wording "portable object" includes any object able to lodge an application, 
such as a memory card or a microcontroller card (smart card). 

The present invention will be explained based on the following drawings : 

5 Figure 1 illustrates the known USB bus topology ; 

Rgure 2 illustrates a smart card based WEB server application ; 

Figure 3 illustrates the invention, the first device being constituted by a HUB 
cellular handset; 

Figure 4 illustrates the invention applied to a secure off-line banking accounts 
10 browsing architecture. 

2 State of the art 

Since a prefen-ed embodiment of the invention uses the USB technology, a short 
reminder of the latter Is now made. 

The USB technology is defined by a standard described in the 'Universal Serial 
Bus specfffcation". Details can be found In this document accessible on Internet 
site www.usb.orq. The USB physical interconnect is a tiered start made of three 
types of devices : 

20 1. The USB root that is hold by a host device such as a PC (Personal 
Computer). 

2. The USB HUB (Interconnect). There is at least one HUB in a USB that is 
the root HUB. There may be up to five levels of HUB on the same bus. 

3. The USB functions that are always connected to a HUB. It may be a 
25 scanner, a printer, a Joystick. . . 
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Figure 1 describes the USB topology. Objects named "Func" are the USB 
functions (printer, scanner...)- 

2.2 Compound device 

5 A compound device is a unique physical device that combines one or more 
functions with a HUB in a single package. There might be a single chip, or a 
more complicated electronic device combining several electronic components. 

2.3 Virtual device and real device 

In the USB standard, a real device (i.e. a scanner, a printer...) is always coupled 
10 with a virtual device that is the device driver allowing the computer application to 
access to the real device functions. 

In case of a compound device, it is associated with a least 2 virtual devices (1 
for the HUB and 1 per function). 

ZJt^ EKampi^ of an application using a ¥VEB server embedded in a 
15 smart cagd 

In figure 2, secure areas are surrounded with a dashed rectangle. This ensures 
the user data are held in secure places. 

It works as follows : 

• Regulariy, and preferably when the network is underused, the smart card 
20 and the bank server synchronize the user data The bank transfers both 

the data to display in an XML file and the pages format in an HTML file. 
Locally, the smart card WEB server Is able to prepare the HTML pages 
including the data in order to answer to the handset browser queries witti 
a ready to use HTML page. 
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• When the user wants to browse its account, it can require the handset 
browser to query the smart card WEB server instead of accessing to the 
banl< server. 

2^ Hie improvement proposed 

5 The application presented chapter 2.4 is interesting, but the user interface is 
limited by the handset keyboard and display. 

TTie goal of the present invention in this context Is to allow the user to browse 
the smart card content from its PC, without having to remove the card from the 
handset. 

10 One should not think the invention is limited to the WEB server. It also applies to 
all the data and applications embedded in the smart card. Furthermore, the 
invention is applicable, not only to smart cards, but also to any combination 
where a removable device is coupled to another device that may be in relation 
with a 3"* device itself compatible with the removable device mentioned here 

15 above. 

For achieving this goaf, the invention concems a first device for delivering a 
service using an application lodged in a portable object, comprising a portable 

20 object reader for receiving said portable object, the. portable object incorporating 
at least one application and the first device including resources for activating 
said application, characterized In that it Includes relay means arranged for 
performing a communication between said portable object reader and a second 
device external to said first device and connected thereto so that the second 

25 device activates at least one application of the portable object independently of 
said resources. 
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The invention described herein may be used to have access to any application 
provided by a mobile communication handset embedding a smart card (e.g. 
GSM, WCDMA...) but not exclusively. 

6 In figure 3, a browser in the PC queries a WEB server present in a USB SIM 
card through a USB HUB present in the cellular handset 

Beyond the cellular handset, the invention is applicable to any portable device 
subject to behave as an intermediate between another portable device It 
eml>eds - such as a smart card - and another equipment that has access to the 
10 embedded device exactly as if the connection was realized without any 
intermediate. 



More particularly, the invention comprises the following features : 

1. Implementing a relaying function on a device A in which the smart card is 
15 inserted- 

This function may be realized using different means, depending on the 
communication capabilities of the communicating object For instance, 
one could use the Internet Protocol, the USB or mixing both on the device 
A. In figure 3, the relaying function Is constituted by the USB HUB in the 
20 cellular handset 

2. This relaying function is used to establish a link between the smart card 
and a device B (here, a PC). In the example of figure 3, the expected 
advantage is using some improved display and entry peripheral 
comparing with the ones existing on the device A. According to the USB 

25 technology, the smart card includes at least one USB device. Here, it 

includes several devices, so that it also includes a corresponding USB 
HUB for gMng access to any USB device. Any application of the card. 
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Shown on figure 3, may be reached by device B through USB HUB of the 
cellufar handset and USB HUB of the card. 

Whatever the technology concerned, device B has access to the card 
through the relaying function and a card reader usually provided in the 
5 cellular handset. Typically but not exclusively, signals emanating from 

device B are managed by the relaying function, bypassing the known 
resources of the cellular handset (at least mobile communication 
application, keyboard and display). Then, the relaying function sends 
corresponding signals to the card, through the card reader. The same 
10 path is used for signals emanating from the card and destined to device 

B, that is through the card reader then through the relaying function. 

3. The link between the smart card and the device B is established in a 
such a way that the device B may have no idea that the smart carcl is in 
reality inserted in a device A that may natively be conceived as a 

1 5 peripheral for the device B. 

4. The type of link or protocol used between the smart card and the device 
A, the device A and the device B, or the smart card and the device B has 
no importance, assuming there is no technical impossibility (e.g. speed 
concerns). The protocols and/or the physical means used can be 

20 different. 

5. Defining a link including the device A, the device B and the smart card is 
the minimum, but several other devices might be inserted in any place of 
the link. 

Some advantaoes of the invention : 

25 1. Having access to the smart card from the device B makes the user more 
comfortable to manage the data in the card (whatever the data are). 
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2. If the device B is equipped with an Internet connection (for example), the 
applications embedded in the smart card could take advantage of this 
connection to upload and /or download data. 

3. Simplifying the access to the card In such a way may help to use the 
5 secure area that is the card. 

4 Implementation exampte 
4.1 Introduction 

This example consists on securely browsing banking accounts from a cellular 
10 handset at any time (i.e. even if the network is not available), and being also 
able browsing the same data from a PC browser with a better user interface 
(taking advantages of the PC display, keyboard, mouse and more). 

It uses the following : 

© An advanced cellular handset connected to the Intemet, compatible wltti 
15 USB smart cards, and embedding the relaying function by including a 

USB HUB. 

© A USB SIM card embedding a WEB server (might be programmed in 
Java for example). 

• A bank WEB server to exchange data with WEB server In the SIM, or to 
20 browse user accounts using a standard WEB browser (e.g. Internet 

Explorer or Netscape-registered trademarks). 

• A PC embedding a USB host (and root HUB) as shown in Tier 1 of figure 
1 , a USB plug, etc. 
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4.2 Components characteristics 
4.2.1 Cellular handset ciiaracteristics 

The cellular handset shall be Immediately connected to the Internet when, being 
compatible with GPRS or UMTS standards, it recognizes the networl<. It shall 
5 have an IP address that may change at each startup (a fixed IP address Is not 
mandatory). Of course, depending on the network status, the IP linl< may 
sometimes be broken. 

A standard WEB browser is available on the cellular handset. It may be 
altematively connected to a server over the wireless connection, or to the server 
10 in the SIM (see §4.2.2). From the browser standpoint there are no differences. 
Every server involved has an IP address. 

The handset and the card are connected using a USB. The SIM, UMTS, GRPS 
or any other applications are viewed as USB devices. 

The handset is directly connected to an extemal USB host such as a PC. It 
15 becomes a USB HUB (see figure 3). 

From the SIM standpoint, the cellular handset is a USB HUB that is connected 
to a host. 

The handset cannot access the GSM, GPRS and/or some other USB devices as 
it is just behaving as a USB HUB (this is for the example, but technical solutions 
20 can be implemented to allow the handset continuing having access to the 
application that may not interest the USB root to which it is connected). 

4.2.2 SIM card characteristics 

In this example, the SIM card embeds at least the following: 

• The SIM standards requirements to allow the handset to have access to 
25 the cellular network (i.e. the GSM, the GPRS and/or equivalent 

applications). 
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• A WEB server able replying to incoming queries and to exchange files 
with a distant server (using FTP or HTTP protocol for instance). 

• An XML parser. 

• Cryptographic means to manage keys, encrypt, decrypt, sign... 
5 • Preferably, a JavaCard virtual machine. 

• All complementary software and drivers to make ail elements listed here 
above to interact. 

The handset has access to the card through a USB. It detects a USB HUB 
followed by several USB devices. 

10 The card embeds a USB HUB and a WEB server. The WEB server virtual 
device (i.e. device driver) implemented on the handset makes it accessible using 
IP (Internet Protocol). The card becomes an Intemet node. Any equipment able 
to have access to this USB, and having the correct device driver, can have 
access to the card WEB server like any other WEB server, thus using an IP 

15 address. 

The IP frames are encapsulated in USB protocol, and the device drivers, both 
on the handset and on the card, provide the interi'ace masking the rea\ data 
transport mean. 

When the USB host detects that the card embeds a USB device that is a WEB 
20 server, it performs the required operation to allocate it an IP address. 

4.2.3 WEB server characteristics 

The (distant) WEB server is a standard server embedding means to exchange 
files with the SIM card WEB server. 

4.2.4 Complementary characteristics 

25 The bank server and the card server should share some cryptographic keys in 
order to exchange files and / or queries securely (in order to protect the user 
banking information). The protocol used here is not important as long as the 
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security level is strong enough. There are many standard solutions existing to 
solve this concern. One of them is using the PKI (Public key Infrastructure) 
architecture. 

4^ Secure off-line banking accounts browsing 

5 Figure 4 shows the architecture of the example, using the components 
described in paragraph 4.2. 

• The handset behavior is the one of a device embedding a USB HUB 
device. 

• The handset is connected to a USB host. This host shows the USB 
^0 HUB in the handset, followed by the one in the smart card, followed by 

the devices in the smart card, particularly the WEB server. 

• The host has the required virtual devices (i.e. the device driver) at Its 
disposal. It is these virtual devices that encapsulate the IP frame to 
make it compatible with the USB. . 

15 The WEB server device in the smart card is consequently accessibje 

from the host (I.e. the PC) like any other IP node. 

® When the user wants to browse its banking information, it uses the 
browser of its PC (e.g. Netscape or Intemet Explorer). He can have 
access to Its banking information either by accessing the Intemet, or 
20 by browsing its data locally by querying the WEB browser in the smart 

card. 

• When the PC (USB host) is connected to the Intemet, the smart card. 
WEB server can take advantage of this situation to synchronize its 
databases with the bank ones. 

25 The link between the handset and the PC does not need to be a USB one. The 
encapsulation process allows using any type of link such as BlueTooth, IP or 
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any other compatible link. The relaying function in the cellular handset will be, in 
each particular case, adapted to the type of link chosen. 

M Alt^nate solutions 

The entire example described here above is based on the USB protocol. Of 
5 course, many other protocols can also match the requirement. One could 
imagine a smart card and a handset natively embedding the IP. Then, the 
switching operation from the USB root to the USB HUB function is not anymore 
required as the smart card and the handset both become an Intemet node. 

When connected to a PC, all the three participants are able to have access to 
10 each other with no other restrictions than the one defined by the IP 
specifications. 



